%
%	Diploma thesis template 2005
%
%       author: lukas.silberbauer(at)gmx.at
%       based upon  "Diplomarbeit mit LaTeX" by Tobias Erbsland
%
%       published under the terms of
%
%  ----------------------------------------------------------------------------
%  "THE BEER-WARE LICENSE":
%  <lukas.silberbauer(at)gmx.at> wrote this file. As long as you retain this notice
%  you can do whatever you want with this stuff. If we meet some day, and you think
%  this stuff is worth it, you can buy me a beer in return.
%  ----------------------------------------------------------------------------
%
%
%

\begin{figure}[H]
	\begin{center}
   		\includegraphics[scale=0.7]{images/component.jpg}
		\caption{Component Diagram}
	\end{center}
\end{figure}
\chapter{Modules}
\section{Overview}
\label{sec:overview}
Figure 2.5 shows a simplified diagram of the program's components and how they work together. Every component has been designed from scratch. The decision against using a graphics library like JMonkeyEngine was made because the game does not need extensive graphics and the overhead of familiarization with the library would possibly be higher than developing the rendering part. Additionally the goal was to learn how such a module can be implemented.
Initially the plan was to use a networking library that handles client connections, time-outs, logins, lobbies, game lists etc. however there was no proper UDP based library we could find and one had to be created. Creating the networking engine was a decent sized chunk of the project.\newline
\section{MoltenCore}
\label{sec:moltencore}

The game server consists of two different servers. The first is the lobby server that maintains the game list. Players perform an anonymous login and can query active games as well as create new ones.

The second server is the game server. Each game server handles an active game instance and lobby. The game lobby is the doorstep before the actual game start where players join the game and can take slots. Once the host starts the game the lobby is discarded and the actual game instantiated. Both the lobby and game use callback interfaces to rely state changes to an interface. As of now there is only a network based implementation of those interfaces, however it would be possible to make local interfaces (on both the client and server) so the program does not access the NIC at all. This has been done to separate the game logic from the propagation to allow easy implementation of single player.

\section{BlazingBubble}
\label{sec:blazingbubble}

The client application contains a GUI to browse through the different menus. The GUI is Swing based but once the game is entered the display switches to JOGL (Java OpenGL). Just like the server, the requestors on the client side are based on an abstract layer but network based implementations are used.\newline
Since the game features fluent motion it was not enough to implement a client as a simple render dummy since at an update time of .1 seconds bubbles would simply teleport around. The client the shares some of the game logic with the server (for example to move around bubbles on it's own). All the common logic was put into abstract classes that are implemented by both the client and server who add their own functionality. In order for this to work the layout of the game field has to be transmitted to the client before the game starts.

\section{Spark}
\label{sec:spark}

Spark is the common package which both server and client use.
\subsection{Graphics engine}
The graphics engine features a render graph that supports sprite nodes (2d images) as well as different transformation nodes (translation, rotation, scaling). The client fills the graph each frame and relays it to the graphics engine which then renders it. Resources can be registered at a resource manager who prevents multiple loading of the same resource. At the moment the only existing resources are textures but the manager is ready to also handle sounds etc.
Another utility in the graphics engine is a camera class to handle display transformations (the camera basically works like the spectator mode in a FPS game).

\subsection{Math}
The math part of the library contains 2d, 3d, 4d vector classes as well as a 4x4 matrix class. The physics in the game logic make use of the vectors to apply movement, gravity etc. to moving objects and the graphics engine use them for transformations such as in the camera or in the scene graph.

\subsection{Network engine}
The networking engine is completely UDP based to increase speed. Packets sent can be made reliable using the engine, when done so the sender remembers which packets were sent and keeps them in a list until an acknowledgement is received. The base of the protocol features clock synchronization between server and clients, time stamps and ids on packets, a client list handled by the engine which is updated as connects are performed. A client that connects to the server is at first unauthorized. The server client list can be extended and the extensions to the protocol done by the servers have to handle the actual authorization/login. The engine then offers functionality to propagate a packet to all authorized clients. Most packets require the client that sends them to be authorized or they are ignored.\newline
At the core of the classes that perform most of this are Demons and DemonHandlers. Demons make sure that received packets are of the proper protocol and dispatch them to the handlers. Handlers have default behavior for special packets such as connection packets or clock sync but also allow to plug in strategies for handling application specific packets not defined in the protocol base.\newline
At this point two functions are missing: keep-alive functionality for kicking clients who crashed or improperly disconnected and re-send functionality for packets that were made reliable (re-send packet every x ms if no acknowledgement was received).\newpage

\section{Level Editor} 
\label{sec:leveleditor}
The whole make up of a level file won't be discussed here. The basic concept is that the level editor describes the physical make up of the level allowing for the bubbles placed in the level to be randomized or of a predetermined color/type and the visuals such as decorations etc. 
\begin{figure}[H]
	\begin{center}
    	\includegraphics[scale=0.5]{images/editor1.png}
		\caption{Level Editor}
	\end{center}
\end{figure}